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REMARKS/ARGUMENTS 

Applicants thank the Examiner for consideration of the Information Disclosure Statement 
filed by Applicants on October 20, 2008. 

By this amendment, Claim 50 is amended and Claims 51-56 are added. No Claims have 
been canceled. Therefore, Claims 1-2, 5-10, 13-28, 30-44 and 46-50 are pending in the 
application. 

Claim 50 is amended to correct a minor informality. Applicants request entry of the 
amendment to Claim 50 pursuant to 37 CFR § 1.1 16(b)(2) as the amendment presents the 
pending claims in better form for consideration on a possible appeal. 

Support for new Claims 5 1 and 53 can be found in Applicants' specification taken as a 
whole including, for example, in paragraphs [0045]-[0048]. (See e.g., paragraph [0048] stating 
"The transformation engine 206 calls the referenced routine to facilitate conversion of "Oracle 
Corporation" to "ORCL" and packages the data according to the format specified for the 
particular web service.") 

Support for new Claims 52 and 54 can also be found throughout Applicants' 
specification. (See e.g., paragraph [0047] stating "Generally, if certain information is needed to 
invoke a web service and that information is not provided by the invoking application, 
transformation information 202 includes a road map as to how to obtain or derive the necessary 
information.) 

New Claims 55 and 56 correspond to previously canceled Claims 3 and 11. 
Each issued raised in the Office Action mailed December 8, 2008 ("Office Action") is 
addressed hereinafter. 
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CLAIM REJECTIONS - 35 U.S.C. § 102 

Claims 1-2, 5-10, 13-28, and 30-44 and 46-50 were rejected under 35 U.S.C. § 102(e) as 
allegedly anticipated by U.S. Pat. Pub. No. 2002/0156685 ("Ehrlich"). Applicants respectfully 
traverse. 

To anticipate a claim of the present application, Ehrlich must teach or reasonably suggest 
"each and every element" of the claim "in as complete detail as is contained in the claim". 
MPEP § 2131 (citing V erdegaal Bros. v. Union Oil Co. of California, 814 F.2d 628, 631 (Fed. 
Cir. 1987; Richardson v. Suzuki Motor Co., 868 F.2d 1226, 1236 (Fed. Cir. 1989)) Further, while 
the claim may be given its "broadest reasonable interpretation" for the purposes of making an 
anticipation determination, the interpretation must be "consistent with the specification" and 
must be "consistent with the interpretation those skilled in the art would reach." MPEP § 21 1 1 
(citing Phillips v. AWH Corp., 415 F.3d 1303 (Fed. Cir. 2005); In re Cortright, 165 F.3d 1353, 
1359 (Fed. Cir. 1999)). 

CLAIM 1 

Present Claim 1 recites, in part: 

1. A method for handling requests for web services, the method comprising the computer- 
implemented steps of: 

receiving at a web services broker, from a particular instance of a client application, a 
request for information, wherein said request includes an identification of a 
particular web service from which said particular instance wants said requested 
information, the request having first input data, the first input data being in a 
form that cannot be used by said particular web service to service requests 
for said information; 

* * * 

in response to receiving said request, the web services broker 
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accessing, based on said identification of said particular web service, 
transformation information that specifies, 

how to transform said first input data associated with said request to 
second input data that said particular web service can use to 
service requests for said requested information, and 

how to invoke said particular web service in a manner required by said 
particular web service, to obtain said requested information from 
said particular web service; 
transforming said first input data to said second input data; and 

invoking, in said manner required by said particular web service, said particular 
web service to obtain said requested information from said particular web 
service. 

Applicants respectfully submit that at least the above-bolded features of Claim 1 are not 
taught or in any way suggested by Ehrlich. 

Claim 1 makes clear that the request from the client application includes (1) an 
identification of the particular web service from which the client application wants the requested 
information and (2) input data that is in a form that cannot be used by the particular web service. 
Based on the identification of the particular web service, the web services broker accesses 
transformation that specifies how to transform the input data so that the particular web service 
can use the transformed input data to provide the requested information. 

The method of Claim 1 may be useful, for example, to allow de-coupled application 
development of the client application and the particular web service. For example, a first team of 
engineers could develop and deploy the client application without concern to what form the 
particular web service expects the input data to be in. An entirely different team of engineers, at 
a later time, could then deploy the web services broker along with transformation information 
that brokers requests from the client application to the particular web service. Specifically, since 
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the web service broker is not in control of how the client application forms the input data the web 
services broker provides transformation information that specifies how to transform input data 
provided by the client application to produce transformed input data that can be used by the 
particular web service. 

EHRLICH'S VIRTUAL SHOPPING CART SYSTEM 
In contrast to the web services broker of Claim 1 , Ehrlich 's shopping system is in control 
of the form of the input data provided by shoppers ("users") of the shopping system. For 
example, Ehrlich' s shopping system provides a user interface that allows a user to search for 
purchase items, add items to a virtual shopping cart, and submit a purchase request to purchase 
items added to the shopping cart. Since Ehrlich' s shopping system provides the interface by 
which a user submits requests, such as purchase requests, to the shopping system, Ehrlich 's 
shopping system is in control of the form of the input data included in the requests. 

Not surprisingly then, Ehrlich' s does not teach or suggest "how to transform said first 
input data associated with said request to second input data that said particular web service can 
use to service requests for said requested information", as featured in Claim 1. Ehrlich does 
describe a "protocol broker" that "chooses for each purchase request, the most appropriate 
protocol and communication mode " for communicating with a merchant site. (Emphasis 
added.) {Ehrlich, [0080]). For example, the protocol broker may choose to communicate with a 
merchant site using the Hypertext Transfer Protocol (HTTP) or the Simple Object Access 
Protocol (SOAP). (Id.) However, Claim 1 is not just about transformation information that 
specifies "how to invoke" a particular web service but is also about transformation information 
that specifies "how to transform" input data provided from a client application. In other words, 
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changing the form of delivery of a message is entirely different from transforming the message 
itself. 

Further, Ehrlich's communication schema does not specify "how to transform said first 
input data associated with said request to second input data that said particular web service can 
use to service requests for said requested information", as featured in Claim 1. Ehrlich describes 
creating a "communication schema" for each merchant that indicates "the required protocol" and 
"has place holders for the item ID, session ID, etc." (Emphasis added.) (Ehrlich, [0088]). 
"During the purchase request, the protocol broker replaces the place holders with the actual 
values or items required by the merchant. . ." (Id.) Thus, while Ehrlich'?, protocol broker may 
replace the place holders with input data from the purchase request, Ehrlich does not describe 
transforming the input data in a purchase request from input data that the merchant site cannot 
use into transformed input data that the merchant site can use. Indeed, given that the Ehrlich's 
shopping system is in control of the form of the purchase request from the shopper, one skilled in 
the art would conclude that the input data in the purchase requests is in a form that the merchant 
site can use. In contrast, Claim 1 expressly requires that the first input data be in a form "that 
cannot be used by said particular web service to service requests for said information". 

Based on the foregoing, Applicants respectfully submit that Ehrlich does not teach or 
suggest at least one feature of Claim 1. Claim 49 recites similar features and is allowable over 
Ehrlich for the same reasons. 

CLAIM 2 

Claim 2 depends from Claim 1 and is therefore allowable over Ehrlich for the reasons 
given above with respect to Claim 1 . In addition, Claim 2 recites additional features that 
independently render Claim 2 patentable over Ehrlich. For example, Claim 2 recites: 
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receiving, from said particular web service, said requested information; and 
transforming, based on said transformation information, said requested information to 
data that said client application can use. 

Thus, in Claim 2, the requested information received from the particular web service is 
transformed to data that the requesting client application can use. The Office Action contends 
that these features specific to Claim 2 are satisfied by Ehrlich at paragraph [0079]. The cited 
portion of Ehrlich describes only creating purchase requests that merchants can understand. 
Nothing in the cited portion of Ehrlich or elsewhere in Ehrlich describes the protocol broker 
transforming, based on accessed transformation information associated with a merchant, 
information received from the merchant site into data that user or shopper can use. In other 
words, Ehrlich describes only one-way transformations (requests from client to service) while 
Claim 2 is about two-way transformations (transformations of requests from client to web 
service and transformations of responses returned from the web service to the client). Thus, 
Claim 2 recites additional features that independently render Claim 2 patentable over Ehrlich. 

CLAIM 5 

Claim 5 recites: 

The method of Claim 1, wherein said transformation information includes a mapping of 
first input data from a first particular client application to second input data that a 
first web service can use, and a mapping of first input data from a second particular 
client application to said second input data that said first web service can use, and 
wherein said first input data from said first particular client application has a different 
form than said first input data from said second particular client application. (Emphasis 
added.) 



OID 2002-186-01 



18 



50277-2234 



Claim 5 is about a many-to-one transformation. In particular, Claim 5 features 
transformation information for mapping, to the same "second input data", input data from two 
clients, where the form of the input data from one client is different from the form of the input 
data from the other client. In contrast, in Ehrlich, purchase requests for a particular item from a 
particular merchant will have the same form (i.e., the form will not vary from client to client). 
For example, using an example provided in Ehrlich, the form of the input data in the purchase 
request for the book titled "Professional Active Server Pages 3.0" described in paragraphs 
[0101]-[01 12] of Ehrlich would be same regardless of which user or shopper submitted the 
purchase request. Thus, it would not make sense for Ehrlich's protocol broker to use 
transformation information like the transformation information featured in Claim 5 that maps, to 
the same "second input data", input data from two clients, where the form of the input data from 
one client is different from the form of the input data from the other client. Consequently, 
Applicants respectfully submit that Claim 5 recites additional features that independently render 
Claim 5 patentable over Ehrlich. 



CLAIM 17 

Claim 17 recites: 

17. A method for handling requests for web services, the method comprising the computer- 
implemented steps of: 

receiving at a web services broker, from a particular instance of a client application, a 
request for information, wherein said request includes an identification of a 
particular instance of said client application, the request having first input data, 
the first input data being in a form that cannot be used by a particular web service 
to service requests for said information; 

wherein the particular web service serves as the source of said requested information and 
is separate from the web services broker; 
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wherein the client application is separate from the web services broker and does not have 
logic for directly interacting with said particular web service; 

in response to receiving said request, based on said identification of said particular 
instance of said client application, the web services broker accessing 
transformation information; 

wherein said transformation information includes a mapping between said 

identification of said particular instance of said client application and an 
identification of said particular web service, the mapping indicating that said 
particular instance prefers said particular web service to service requests 
from said particular instance for said requested information; 

wherein said transformation information specifies how to transform said first input 
data associated with said request to second input data that said particular 
web service can use to service requests for said requested information; and 

based on said transformation information, the web services broker transforming 
said first input data to said second input data. 

Applicants respectfully submit that at least the above-bolded features of Claim 17 are not 
taught or in any way suggested by Ehrlich. 

Claim 17 makes clear that the request from the client application includes: 

(A) an identification of the particular instance of the client application AND 

(B) input data that is in a form that cannot be used by a particular web service. 

Based on the identification of the particular instance of the client application, the web services 

broker accesses transformation information that specifies: 

(1) a mapping between the identification of the instance of the client application and an 
identification of a particular web service from which the instance of the client application 
prefers to receive the requested information AND 
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(2) how to transform the input data so that the particular web service can use the 
transformed input data to provide the requested information. 

Thus, in Claim 17, a mapping in the transformation information accessed by the web services 
broker specifies the web service from which the instance of the client application prefers to 
receive the requested information. 

The Office Action contends that Ehrlich's "merchant protocol data" is equivalent to the 
transformation information of Claim 17. (See Office Action, page 6). However, the merchant 
protocol data retrieved from the merchant schema database of Ehrlich corresponds to the 
merchant specified in the purchase request and not the particular instance of the client 
application that sent the purchase request. For example, paragraph [0113] of Ehrlich states with 
respect to an example purchase request "[t]he protocol broker analyzes and parses the SOAP 
purchase request, retrieves the merchant protocol data for AlBooks.com from the merchant 
schema database 120..." In this example, "AlBooks.com" identifies the merchant, not the 
particular instance of the client application that sent the purchase request. In contrast, Claim 17 
expressly requires that the "in response to receiving said request, based on said identification of 
said particular instance of said client application , the web services broker accessing 
transformation information". Ehrlich does not teach or suggest this feature of Claim 17 at least 
because nothing in Ehrlich describes accessing merchant protocol data based on an identification 
of the particular instance of the client application making a purchase request. 

Furthermore, Claim 17 recites the following feature that is similar to features recited in 

Claim ldiscussed above: 

wherein said transformation information specifies how to transform said first input data 
associated with said request to second input data that said particular web service 
can use to service requests for said requested information; and 
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based on said transformation information, the web services broker transforming said first 
input data to said second input data. 

For the reasons given above with respect to Claim 1, Applicants respectfully submit that 
Ehrlich also does not satisfy the above features of Claim 17. 

Based on the foregoing, Applicants respectfully submit that Ehrlich does not teach or 
suggest at least one feature of Claim 17. Claim 50 recites similar features and is allowable over 
Ehrlich for the same reasons. 

REMAINING CLAIMS 
The pending claims not discussed so far are dependant claims that depend on an 
independent claim that is discussed above. Because each dependant claim includes the features 
of claims upon which they depend, the dependant claims are patentable for at least those reasons 
the claims upon which the dependant claims depend are patentable. Removal of the rejections 
with respect to the dependant claims and allowance of the dependant claims is respectfully 
requested. In addition, the dependent claims introduce additional features that independently 
render them patentable. Due to the fundamental differences already identified, a separate 
discussion of those features is not included at this time. 

CONCLUSION 

For the reasons set forth above, it is respectfully submitted that all of the pending claims 
are now in condition for allowance. Therefore, the issuance of a formal Notice of Allowance is 
believed next in order, and that action is most earnestly solicited. 

The Examiner is respectfully requested to contact the undersigned by telephone if it is 
believed that such contact would further the examination of the present application. 
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Please charge any shortages or credit any overages to Deposit Account No. 50-1302. 



Respectfully submitted, 

Hickman Palermo Truong & Becker LLP 



Date: February 8, 2009 /AdamCStone#60531/ 

Adam Christopher Stone 
Reg. No. 60,531 

2055 Gateway Place, Suite 550 
San Jose, California 951 10-1089 
Telephone No.: (408) 414-1080 ext. 231 
Facsimile No.: (408) 414-1076 
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